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REMARKS 
Status Summary 

Claims 1-53 are pending in the present application. No claims have been added 
and no claims have been canceled. Therefore, upon entry of this amendment, claims 
1-53 will remain pending. No new matter has been introduced by the present 
amendment. Reconsideration of the application as amended and based on the 
arguments presented below is respectfully requested. 

Claim Objections 

Claim 22 is objected to as containing informalities. Namely, the word "Indian" 
was unintentionally used in place of "Endian" in two instances. In response, the 
objected claim has been amended per the suggestion of the Examiner. Thus, 
applicant respectfully submits that the objection to claim 22 should be withdrawn. 

Claim Rejections - 35 U.S.C. § 102 
Claims 1-53 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
U.S. Patent No. 6,772,320 to Rai et al . (hereinafter "Raj"). The rejection is respectfully 
traversed. 

Independent claim 1 recites a method for exchanging data between a first 
component and a second component having a respective first native data structure 
format and a second native data structure format. Notably, claim 1 recites a method of 
exchanging native data structure format information between the first and second 
components (e.g., a primary server and a backup server). In one embodiment, the 
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first component may generate data in the first native data structure format, e.g., NDSF 
data 115, which is subsequently transmitted to the second component. The second 
component translates the received NDSF data 115 into data that is in the second 
native data structure format, e.g., NDSF data 125, by using the exchanged native data 
structure format information. (See applicant's specification, paragraphs [0018] and 
[0019] in US 2005/0216896). 

In one embodiment, the native data structure format information exchanged 
between the first component (e.g., component 110) and second component (e.g., 
component 120) may include a translation map 150. Paragraph [0019] explains that in 
order to facilitate the translation of data exchanged between the first component and 
the second component, translation map 150 is transmitted from the first component to 
the second component with or after the transmission of NDSF data 115. The 
specification also mentions various methods in which translation map 150 may be sent 
(e.g., repeatedly, prior to sending NDSF data, immediately after establishing a 
communications link, etc.). In addition, the second component may also provide a 
translation map 160 to the first component in the same manner translation map 150 is 
exchanged. (See paragraph [0019]). 

As mentioned above, the second component utilizes translation map 150 to 
translate NDSF data 115 into NDSF data 125. A translation map, or any other form of 
native data structure format information, is used when the native data structure 
formats of the first and second components differ. For example, suppose the second 
component normally employs five variables during data processing, but receives six 



-11 - 



Serial No.: 10/809,963 



variables in the received NDSF data 115. (See applicant's Figure 1). The second 
component may then utilize translation map 150 (and possibly its own translation map 
160) to determine how to process the extra variable present in NDSF data 115. (See 
page 2, paragraph [0020]). Depending on translation map 150 (and possibly 
translation map 160), data variables in NDSF data 115 may be rearranged, 
segmented, discarded, etc., during the translation process so that the data may be 
translated into a compatible form used by the second component. Moreover, 
translation map 150 also informs the second component how to handle an unfamiliar 
or disproportionate number of bits contained within each variable as well. (See 
Applicant's specification, paragraphs [0020] and [0021]). Independent claims 29, 38, 
45, and 48, like claim 1 , each recite the exchange of data structure format information 
between first and second components that have different native data structure formats. 
Thus, claims 1, 29, 38, 45 and 48 recite exchanging native data structure format 
information, an example of which is translation map 160, between components that 
have different native data structure formats- 
There is absolutely no teaching or suggestion in Raj of exchanging data 
structure formats between first and second components between components that use 
different native data structure formats as recited in independent claims 1 , 29, 38, 45, 
and 48. In contrast, Raj teaches a method for converting data for computer systems 
having different data storage architectures. The method is primarily used for 
converting data stored in little endian and big endian formats and relies on creating a 
data structure that is used to convert the data utilizing embedded macros that are not 



- 12- 



Serial No.: 10/809,963 



executed at run time. (See Raj, Abstract). Applicant respectfully submits that Raj 

does not teach or mention the exchange of native data structure format information 

between the first and second components. On page 3 of the Official Action dated 

6/7/2007, the Examiner alleges that column 1, lines 50-60 of Raj teaches the 

exchanging of native data structure format information. Specifically, column 1, lines 

50-60 of Raj recites: 

However, when a big endian machine and a little endian machine 
attempt to communicate through memory reads and writes to each other , 
the data must be re-formatted to be accessible by the other machine. In 
order to accomplish this programmer's have developed code that swaps 
bits and bytes of data within words being accessed . However, this 
development of code by different programmers is time-consuming and 
prone to error. Further, this code is often specific to each specific 
application generated. Therefore, one of the purposes of direct memory 
access for communications is defeated by the lengthy time requirements 
for this conversion process. (Emphasis added). 



The Examiner's attention is directed to the fact that this cited section addresses 
the transfer of the actual data to be converted and the communication between a big 
endian machine and a little endian machine. The section further describes that the 
reformatting of the data is accomplished by swapping bits and bytes of data within the 
words being accessed. The "swapping" of bits is typical for reformatting big endian 
and little endian data (e.g., reformatting may be accomplished by simply swapping the 
order of data since little endian architecture requires the least significant byte to be 
placed in a lower memory address, whereas the most significant byte is placed in a 
lower memory address in a big endian architecture). (See Raj, column 1 , lines 35-42). 
Namely, this section cited by the Examiner, or any other section in Raj for that matter, 
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fails to teach the exchange of any native data structure format information. Rather, 
this section only teaches the exchange of the data to be converted. Applicant submits 
that the exchange of native data structure format information is not needed for the 
subject matter presented in Raj because the byte positions are simply rearranged 
based on whether big endian or little endian byte order is desired (See Raj, column 4, 
line 48 to column 5, line 14; Figure 3). Also, Raj does not address the situation where 
data sent from a first component differs from a second component's native data 
structure format, especially where the number of variables in the data, and even the 
byte sizes within the variables, are completely different. For instance, Raj does not 
teach or mention that variables within data to be translated may be added or deleted. 
In Raj, the simple swapping of variables would not suffice in the scenario where the 
actual number of variables of the data received does not match the number of 
variables typically handled by the component. This is one reason why the exchange of 
native data structure format information between the first and second components is 
facilitated in the claimed subject matter. Because Raj does not teach the exchange of 
native data structure format information of any type, applicant respectfully submits that 
claim 1 is not anticipated by Raj and therefore, the rejection of claim 1 under 35 U.S.C. 
§ 102 should be withdrawn. Furthermore, since independent claims 29, 38, 45, and 48 
include a similar element of exchanging native data structure format information, 
applicant submits that claims 29, 38, 45, and 48 are also not anticipated by Raj and 
the rejection of these claims under 35 U.S.C. § 102 should be withdrawn for at least 
the reasons presented above. 
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Dependent claims 2-28, 30-37, 39-44, 46-47, and 49-53 depend from claims 1 , 
29, 38, 45, and 48 and recite additional features thereof. As such and for the same 
reasons set forth above, applicant submits that claims 22-28, 30-37, 39-44, 46-47, and 
49-53 are not anticipated by Raj. Therefore, applicant submits that the rejection of 
these claims under 35 U.S.C. §102 should be withdrawn. 

CONCLUSION 

In light of the above amendments and remarks, it is respectfully submitted that 
the present application is now in proper condition for allowance, and an early notice to 
such effect is earnestly solicited. 

If any small matter should remain outstanding after the Patent Examiner has 
had an opportunity to review the above Remarks, the Patent Examiner is respectfully 
requested to telephone the undersigned patent attorney in order to resolve these 
matters and avoid the issuance of another Official Action . 
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DEPOSIT ACCOUNT 
The Commissioner is hereby authorized to charge any fees associated with the 
filing of this correspondence to Deposit Account No. 50-0426 . 

Respectfully submitted, 

JENKINS, WILSON, TAYLOR & HUNT, P.A. 
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